کامپیـــــــوتر آخرین مطالب
آرشيو وبلاگ نويسندگان چهار شنبه 12 مهر 1391برچسب:, :: 9:54 بعد از ظهر :: نويسنده : amir
با استفاده از تکنیکهایی مفید، از روشهایی مانند XP،Scrum و RUP میتوان رویهای مناسب برای تولید نرمافزارهای کوچک بهوجود آورد. همچنین میتوان از روشهایPSP و TSP نیز که برای تولید نرمافزارهای کوچک مناسب هستند استفاده نمود و بهوسیله این روشها کیفیت و قابلیتهای نرمافزارها را بالا برد و در حداقل زمان ممکن نرمافزار را تهیه نمود.
پیروی از یک رویه منظم تولید نرمافزار به تولیدکنندگان نرمافزار کمک میکند امور مربوط بهتولید نرمافزار را منظم و پروژه را در حداقل زمان ممکن و با کارایی بالایی انجام دهند. در حقیقت یک رویه یا Process از مراحل مختلفی تشکیل شده است. این مراحل فعالیتهای مربوط به رویه را مشخص مینمایند و تعیین میکنند که این فعالیتها باید چگونه انجام شوند. پیروی از این مراحل به اعضای پروژه دریابند یاری میرساند که چه کاری را چه موقع و چگونه انجام دهند همچنین این کار میان اعضای گروه نیز هماهنگی به وجود میآورد. از آن جایی که منابع موجود و نیازهای کاربران هر نرمافزار با دیگری تفاوت دارد، فرایند تولید نرمافزارهای گوناگون نیز متفاوت است. انجمن IEEE رویه یا فرایند تولید نرمافزار را این گونه تعریف میکند: رویه تولید نرمافزار در واقع شامل مراحلی مانند جمعآوری نیازهای کاربران ، طراحی سیستم با استفاده از تحلیل این نیازها و نوشتن کدهای نرمافزار با استفاده از طرح نرمافزار است. همچنین بر اینباور است که از آن جایی که کیفیت و بهرهوری نیروی کار با کیفیت روند تولید نرمافزار ارتباط مستقیم دارد، طراحی و مدیریت رویه تولید نرمافزار از اهمیت شایانی برخوردار است. برای طراحی یک رویه تولید نرمافزار می توان از روشهای متفاوتی استفاده نمود و از آن جایی که هر پروژه نرمافزاری با دیگر پروژهها متفاوت است، میتوان گفت که رویه تولید آن پروژه نیز با دیگر پروژهها تفاوت دارد. در واقع میتوان گفت: انتخاب این روشها رابطه مستقیمی با اندازه گروه در پروژه دارد و نرمافزارهای بزرگ و کوچک نیاز به رویههای تولید متفاوت دارند. در ادامه این مقاله روشهای تولید نرمافزارها، به خصوص نرمافزارهای نسبتاً کوچک که از گروههای تولید نرمافزاری کوچکتری استفاده میکنند، بررسی میشوند و مورد ارزیابی قرار میگیرند. روش SCRUM در روشهای قدیمی و معمول ساخت نرمافزار، طراحان نرمافزار معمولاً ابتدا فرض میکنند که تمامی نیازهای کاربران سیستم را درک کردهاند. اما همیشه نیازهای کاربران سیستم در ابتدا مشخص نیست و کاربران ممکن است در همان مراحل ابتدایی، نیازهای خود را تغییر دهند و این چیزی است که برنامهنویسان و طراحان سیستم همیشه از آن شکایت میکنند و به دنبال راهحلی برای رفع این موضوع میگردند. بهعنوان مثال مدل قدیمی آبشاری (waterfall) را در نظر بگیرید. این مدل حاوی مشکلات فراوانی است که به صورت مستقیم به غیرقابل انعطافبودن این مدل ارتباط دارد. این مدل مانند یک جاده یک طرفه میباشد که وقتی اتومبیل در آن حرکت میکند، نمیتواند مسیر خود را تغییر دهد و در جهت دیگری حرکت کند. در ابتدای کار کاربر سیستم ممکن است نظراتی در مورد سیستم داشته باشد ولی نمیتواند ببیند که سیستم چگونه کار خواهد کرد و در نتیجه ممکن است وقتی که سیستم آماده شد، از ساختار و کارایی آن راضی نباشد و تقاضای تغییر در سیستم را بنماید. در نتیجه اگر بتوانیم کاربر را از ابتدا در جریان ساخت نرمافزار قرار دهیم، ممکن است که این مشکل حل شود؛ زیرا میتواند نظرات خود را در طول مدت ساخت و قبل از اتمام کار اعلام کنند و در نتیجه از نرمافزار تهیه شده راضی باشد. روش Scrum همانند پروسههای دارای مرحله برنامهریزی مقدماتی یا Initial Planning است. در این فاز اعضای تیم باید یک نقشه مقدماتی و یک معماری سیستم قابل تغییر به وجود آورند. بعد از این فاز یک سری از Sprintها به صورت مرتب و جزء جزء نرمافزار مورد نظر را به وجود میآورند. انجام دادن هر Sprint ممکن است از یک تا چهار هفته به طول بینجامد و مجموع این Sprintها نرمافزار کاملی را بهوجود میآورند. فهرست تکالیف در هر Sprint به Backlog مشهور است که تکالیف تیم عملیاتی در هر Sprint را مشخص میکند. این Backlog در هر Sprint بروز میشود و هر تکلیف براساس اهمیتی که دارد در فهرست تکالیف تعیین اولویت میگردد. هر فرد در گروه یک کار یا تکلیف خاص از این فهرست را به عهده میگیرد و موظف میشود تا شروع Sprint بعدی آن را به اتمام برساند. وقتی که یک Sprint شروع شد، دیگر انجام هیچ تغییری در تکالیف امکان ندارد و حتی درخواستکننده نرمافزار نیز حق تغییر یا درخواست نیاز دیگری در نرمافزار را نخواهد داشت. البته درخواستکننده میتواند از قسمتی از نرمافزار که باید در هر مرحله تولید شود بکاهد، اما نمیتواند تاریخ تحویل آن قسمت را تغییردهد. شاید بتوان گفت که این کار باعث ایجاد نظم در گروه میشود و تاریخ تحویل نرمافزار به تعویق نخواهد افتاد. علاوه بر این، در طول هر Sprint گروه موظف است روزانه جلساتی جهت بررسی روند پیشرفت و قابلیتهای نرمافزار داشته باشد که این نیز به هماهنگی بیشتر گروه کمک خواهد کرد. در این جلسات که معمولاً به صورت روزانه است، سه گروه میتوانند شرکت کنند: گروه تهیهکننده نرمافزار، مدیریت، و درخواستکنندگان نرمافزار. در طول این جلسات مسئول جلسه که اغلب مدیر پروژه است، از تمامی اعضای تیم سه سؤال می پرسد: 1- مسئولیت شما (تکالیف) از جلسه قبلی تاکنون چه بوده است و آیا توانستهاید این تکالیف را به اتمام برسانید؟ 2- در طول این دوره به چه مشکلاتی برخوردهاید؟ 3- بر طبق فهرست وظایف، مسئولیت شما از حالا تا جلسه بعدی چه خواهد بود؟ مدیر Scrum در حقیقت مسئولیت شناسایی تکالیف محوله به اعضا، بررسی روند تکمیلی ساخت نرمافزار، بررسی قابلیتهای اعضای گروه و فعالیت در راستای کم کردن ریسک در پروژه را داراست. در جواب این سؤال باید یادآورشد که در Scrum هر مرحله یا Sprint قسمتی از نرمافزار را آماده می کند. در این روش می توان پیشرفت در تولید نرمافزار را در هر مرحله به خوبی احساس نمود. علاوه بر این، گروه میتواند پس از اتمام هر Sprint تصمیمگیریکند که آیا می خواهد به کار روی پروژه ادامه دهد یا انجام پروژه مذکور غیرممکن است. روش Scrum وقتی میتواند بیشتر مفید باشد که در ابتدای پروژه نیازهای کاربران به صورت دقیق مشخص نباشد و یک گروه کوچک مسئول پروژه نرم افزاری باشد. نتایج تحقیقاتی که اواخر سال 2005 روی چندین شرکت تولیدکننده نرمافزار در کشور انگلستان انجام دادم، نشاندهنده این بود که شرکتهایی که از Scrum استفاده کرده بودند با حدود چهارصددرصد افزایش در بهرهوری کار مواجه بودند. البته این رقم در گروههای نرمافزاری مختلف متفاوت بود و میتوان گفت عوامل انسانی از جمله مدیر پروژه نقش بسیار مهمی در افزایش یا کاهش راندمان پروژه ها دارند. شاید این سؤال در ذهن شما به وجود آید که چرا Scrum ممکن است برای تولید نرمافزارهای کوچک راه حل خوبی باشد؟
نظرات شما عزیزان: پيوندها
|
|||
![]() |